Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

Defining security groups

Progress Dynamics implements security groups. Security groups allow you great flexibility, permitting you to set up any security structure. You can assign users to multiple security groups, and in turn you can link a security group to one or more other security groups. User permissions are accumulated from all groups a user belongs to, and from all groups to which those groups, in turn, belong.

Note: Progress Dynamics does not use security hierarchies. In a security hierarchy, you cannot consolidate security groups in different levels in the hierarchy, and you can only assign groups at the bottom of the hierarchy to users. As you must assign each security group to the user individually, a hierarchical approach results in increased administration. A security hierarchy incurs a high performance overhead, as the hierarchy must be navigated every time security rights need to be determined.

Consolidated groups

Consolidated groups are security groups that exist only to group other security groups. You can then assign these consolidated security groups to users. These consolidated groups do not have any security allocations against them directly. Use consolidated groups to simplify security administration. You do not need to flag them in any way. Progress Dynamics assumes that a security group is a consolidated group if it is linked to one or more other security groups but does not have security allocated specifically against it. For example, instead of having to allocate several groups to every user, you can create a consolidated group and link the allocated groups to it. You can then assign just this one consolidated group to every user.

Note: Progress Dynamics assumes that security groups with no security allocated against them exist only to consolidate other security groups into one security group. Progress Dynamics does not look at consolidated groups (that is, any group that has no security allocated against it) when it checks security.

Least restrictive rule

Users belonging to multiple security groups must perform all the actions required in each group. If one group grants less access than another, or revokes access granted in another, the users will not be able to perform all the actions necessary for one of their roles. For this reason, the least restrictive security option always takes precedence, giving users all access necessary to perform their roles.

If security allocations from different security groups contradict each other, Progress Dynamics uses the least restrictive security allocation. For example, if you have secured a field as Full Access in one security group, and Read Only in another security group, Progress Dynamics will grant Full Access.

In a grant model, the users gain access if they have been granted access in any of the groups they are linked to. If they have been granted access in more than one group, they get the least restrictive access.

In a revoke model, you must revoke access in every group to which the users are linked. If access has not been revoked in all security groups the users are linked to, they will gain access. If access has been revoked differently in different groups, they get the least restrictive access.

Security override rule

Security that you set up at the user-level always overrides security set up at the group-level. This rule lets you set up user-specific exceptions. This rule means that if you allocate any security against the user directly, the system will use that security immediately. The system will not do any further checks against the security groups to which the user belongs.

Where you specify security at the user level, Progress Dynamics ignores the security specified at the security group level.

Security groups and the revoke security model

Figure 3–2 provides an illustration of how security groups work in the Revoke security model.

Figure 3–2: Revoke model example

In this revoke model example, Groups A and C are consolidated into Group AC. Groups AC and B are consolidated into Group ACB.

The following scenarios describe how this example revoke security model works:

A user belonging to Group B has full access to field user_login_name, but does not have access to the Modify and Details actions.
A user belonging to Group AC has read-only access to the user_login_name field. Because of the least-restrictive rule, the user does not have access to the Add action, but does have access to the Details and Modify actions. (Access to an action would have to be revoked in both A and C for it to be revoked in AC.)
A user belonging to Group ACB, has full access to the user_login_name field. Because of the least-restrictive rule, the user has access to the Add, Modify, and Details actions.

Security groups and the grant security model

Figure 3–3 provides an illustration of how security groups work in the grant security model.

Figure 3–3: Grant model example

In this grant model example, as illustrated in Figure 3–3, Groups A and C are consolidated into Group AC. Groups AC and B are consolidated into Group ACB.

The following scenarios describe how this example grant security model works:

A user belonging to the Default Security Group and Group C has access to:
The Login screen, Exit button, Default menu, Field user_login_name (Hidden), Action Delete, and data security customer.
All actions and fields not set up in the General Security Manager (GSM) gsm_token and gsm_field tables.
A user belonging to the Default Security Group and Group AC has access to:
The Login screen, Exit button, default menu, user_login_name field (read-only), Action Add, Action Details, Action Delete, and data security customer.
All actions and fields not set up in the gsm_token and gsm_field tables.
A user belonging to only Group ACB has access to:
Menu Item Product Control, Action Modify, data range customer, user_login_name field (read-only), Action Add, Action Details, Action Delete, and data security customer.
All tokens and fields not set up in the gsm_token and gsm_field tables.

In this example, this group affiliation would not be of much use, as the user cannot access the login screen. To resolve this problem, you could instead link the user to security group A and allocate field security directly against the user record: field user_login_name – Full Access. The user now has access to:

User_login_name field (full access), Action Add, Action Details.
All tokens and fields not set up in the gsm_token and gsm_field tables.

Creating a new security group

To determine how to set up a security group for your application, identify which functions must be secured routinely for users performing the same function. Then create a security group and secure the applicable objects in that security group. For example, you might create a group for Sales Managers and another group for Sales Representatives.

Avoid trying to set up security based on how you anticipate a security group is going to interact with other security groups. Instead, regard each security group as a totally independent unit, and leave it to the system to accumulate and resolve conflicting security.

To set up a new security group:

From the Administration window, choose Security Security Control.
In the Security Control window, expand the Security Control node, then the Security Maintenance node.
Select the Security Groups node. The Security Groups Maintenance frame appears, as shown:



Choose Add record . The fields in the Details tab become enabled, as shown:



Enter the name and the description of the group.
Select the Default security group toggle box if you want all new users (that is, those you create after you save this toggle box setting) to be linked to this security group.
Choose the Save button. The new security group appears in the browse at the top of the Security Groups Maintenance frame.

Creating a consolidated group

If you can identify security groups that are all going to be assigned to users performing the same role on a regular basis, consolidate the set of security groups into one security group. Then assign the one consolidated security group to your users.

To set up a consolidated security group:

Create a group.
Do not specify any allocations against the group.
Under the This group linked to groups tab, specify the groups you want to consolidate as subgroups of this group.

Creating a security group based on an existing user

You can convert an existing user into a security group.

Note: A user cannot log in as a security group.

To create a new security group based on an existing user:

From the Administration window, choose Security Security Control.
In the Security Control window, expand the Security Control node, then the Security Processing node.
Choose the Group Processing node. The Create security group from user frame appears, as shown:



In the User field, specify the user on whom you want to base the new security group. The utility will move the security allocations from the user you specify to the new group.

If the user that you specify is a profile user, then the utility moves (to the new group) only those security allocations that the profile user and all users based on the profile user share in common. The utility leaves alone any allocations that are not common. The utility then links the profile user, and all users based on the profile user, to the new group.

If you specify a user who is not a profile user, then the utility moves all security allocations from the user to the new security group and then links the user to this new group.

Type in the New security group name.
Choose Process.

Specifying default security groups

You can specify default security groups. Determine the default functionality to which every user in your system needs access (for example, the login screen). Allocate this security to a security group, and save it as a default security group. All users in your system will automatically have access to the functionality defined in the default group. Also, when you add a new user to the system, the framework automatically links the new user to any default groups.

To create a default security group:

In the Security Control window, choose the Security Maintenance Groups node. The Security Group Maintenance frame appears, as shown:



Select an existing group or choose Add record to create a new group.
In the Details tab, check the Default security group toggle box, then choose Save.

Whenever you create a user, the framework automatically links the new user to this (and any other) default security group.

Linking a company to a security group

When you create a group, you can link the group to a specific login company. In addition, when you link users to groups, you can specify that a security group only applies when the user logs into a certain company. This functionality lets you specify what functions the user fulfills in different companies. Alternately, you can specify that a security group applies application-wide.

For all security groups you have created, decide if the security group applies to only certain login companies in your application, or all. If only to certain login companies, link the applicable security groups to those companies.

Of the security groups allocated to your users, check if certain security groups only apply to that user when logging into a specific company. Update the security group allocation to indicate which security groups apply to which companies for which user. By default, the security groups allocated to a user will apply for all companies the user logs into.

Linking users to a security group

Decide which security groups apply to which users, then link them. If you want to override security set up in the security group for a single specific user, allocate the security against the user directly. Remember, for security allocated directly to a user, the security set up against the user’s security groups is not checked.

When you link security groups to a profile user, the users based on that profile user will also be linked to the security group.